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BACKGROUND OF THE INVENTION 
1. Field of the Invention 

The invention generally relates to packet data transmission in wireless networks, 
such as cellular mobile networks and wireless local area networks, and in particular 
to protocols providing the routing of packet data through the core network of the 
wireless network. 

In the wireless network, a mobile data terminal (herein called "mobile host", MH), 
such as a mobile phone or a portable personal computer, is providing a packet 
switched data connection, for example to a server computer in the Internet or to 
another mobile data terminal in another wireless network. Packet data in this context 
may contain hypertext markup language (HTML) documents or coded audio and 
video signals like voice over Internet protocol, video conferencing signals or video 
streaming. Especially for real time audio and video data, but also for other types of 
data, uncontrolled delay or even loss of data packets in the transmission can impact 
the practical use up to complete uselessness. To handle this problem, mechanisms 
have been introduced in the related protocols to ensure a certain quality of service 
(QoS) of the packet data transmission. 

The wireless network consists of a so called core network and a plurality of radio 
access network (RAN) domains providing wireless connection between the mobile 
host and the core network. The core network has an external connection through a 
gateway (GW) to other networks, like for example the world wide Internet. 

A scenario is considered, in which multi-protocol label switching (MPLS) is deployed 
as a transport technology between the gateway (GW) and the radio access network 
domains. To assure the needed QoS requirements, MPLS-based tunnels between 
the GW and the RAN domains are set up deploying traffic engineering (TE) options 
of MPLS signalling. A tunnel is a virtual connection between two nodes of a network, 
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wherein payload data is encapsulated with lower layer protocol headers and 
transmitted over the network, in order to provide a transparent point-to-point 
connection. The data packets destined to a roaming MH are tunnelled in such MPLS- 
based tunnel over the core network. 

in the context of this invention it will be differentiated between handover procedures 
managed in the RAN and such managed in the core network assuring the re-routing 
of the data triaffic (or of the data tunnels). Since the MH changes the node of 
attachment (NoA, i.e. egress LSR of the data tunnel) while moving, it is necessary to 
provide a method for redirecting packet data in the core network such that they reach 
the MH without undue delay or even loss of packets. 

2. Description of the Related Art 

Mobility management solutions for data communication, for example in second 
generation (Global System for Mobile Communication, GSM) and third generation 
(Universal Mobile Telecommunications System, UMTS) cellular networks, are 
proprietary and technology specific. The Internet Engineering Task Force (IETF) has 
standardized mobility management within Internet protocol-(IP)-based networks 
known as Mobile Internet protocol (MIP). IP routing uses the packet's IP address as 
information about the destination point, i.e. the IP address determines 
unambiguously the geographical point of attachment. MIP extends the classical IP 
routing with the mobile host's possibility to be associated with two IP addresses: a 
static "home" address and a dynamic "care-of-address" (CoA), which reflects the 
MH's current point of attachment. More detailed information about the functionality of 
MIP can be found in C. Perkins et. al., "IP Mobility Support for IPv4", RFC 3344, 
August 2002. 

The MPLS concept employs two distinct functional planes: control plane and 
forwarding plane. In the control plane, standard routing protocols are used to 
exchange information between routers to build and maintain a forwarding table. Such 
standard protocols are for example "open shortest path first" (OSPF) and border 
gateway protocol (BGP). In the forwarding plane, when data packets arrive, the 
forwarding component searches in the forwarding table to make a routing decision for 
each packet. To each packet a short label with fixed length is attached identifying the 
forwarding equivalent class (FEC). The forwarding plane in MPLS is based on label 
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swapping algorithm. The label switch (known as Label Switch Router, LSR) as a 
node of the network performs a routing table lookup, maps the packet to a FEC and 
then assigns a label to the packet before fonA/arding it to the next LSR in the label 
switched path (LSP). A detailed specification of MPLS concept can be found in E. 
Rosen, Floyd, A. Viswanathan, and R. Gallon, "Multiprotocol Label Switching 
Architecture", RFC 3031, January 2001. 

The MPLS described above has still the hop-by-hop forwarding paradigm inherited 
from standard IP routing. To increase the efficiency and the reliable network 
operations in the MPLS domain, as well as to meet QoS requirements, traffic 
engineering (TE) capabilities for MPLS can be deployed. The requirements for TE- 
MPLS are defined in D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, 
"Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. 
These capabilities can be used to optimise the utilization of network resources and to 
enhance traffic oriented performance characteristics. A LSP set up by TE 
functionality is called TE-LSP or LSP tunnel, since the flow along an LSP is 
completely identified by the label applied at the ingress node of the path, 

MPLS is generic rather than proprietary transport technique, however, mobility is not 
available in the specifications. Several recent publications have considered the 
deployment of MPLS in mobile networks. Whereas F. Chiussi, D. Khotimsky, and S. 
Krishnan, "A Network Architecture for MPLS-Based Micro-Mobility", in Proc. of the 
Wireless Communications and Networking Conference (WCNC), March 2002 and T. 
Yang, Y. Dong, Y. Zhang, and D. Makrakis, "Practical Approaches for Supporting 
Micro Mobility with MPLS", in Proc. of the International Conference on 
Telecommunications (ICT), June 2002 consider micro-mobility within the mobile 
operator's network, the proposal described in Z. Ren, C.-K. Tham, C.-C. Foo, C.-C. 
Ko, "Integration of Mobile IP and Multi-Protocol Label Switching", in Proc. of the 
International Conference on Communications (ICC), June 2001, is a macro-mobility 
scheme. To deploy mobility in MPLS, MPLS Label Switched Path (LSP) tunnel 
switching is needed. The mechanisms presented in the cited documents are based 
on the assumption that both Mobile IP and MPLS are deployed together and the MH 
will obtain a new IP CoA address after a handover. 

In future wireless networks, conversational services (voice and video conferencing) 
should be supported. To simplify the maintenance of traffic flow in downstream and 
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upstream data paths, bi-directional MPLS tunnels can be used to connect the 
Gateway and the NoA. The setup of bi-directional LSPs is described in detail in R. 
Dube, M. Costa, "Bi-directional LSPs for classical MPLS", Internet Draft, Work in 
Progress (in context of "classical" MPLS) and L. Berger et.al., "Generalized Multi- 
Protocol Label Switching (GMPLS) Signalling Resource Reservation Protocol-Traffic 
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003 (in context of 
Gieneralized MPLS), which differ only in the message format rather than the 
procedures for the LSP setup. Using the described mechanism, bi-directional LSP 
setup is indicated by the presence of an "Upstream Label" in the Path message. With 
respect to the signalling procedures, there is no difference to the setup of uni- 
directional tunnels. For more details refer to the documents cited above. 

Herein below, the term "initiator" is used to represent the LSR that initiates LSP setup 
and the term "terminator" to represent the LSR at the other end of the LSP. This 
means that the ingress LSR in case of uni-directional tunnel corresponds to initiator 
and the egress LSR corresponds to terminator. As the procedures to set up uni- 
directional and bi-directional MPLS tunnels do not differ, for the description of the 
invention, uni-directional tunnels will be regarded and the terms ingress and egress 
LSR will be used for the ease of explanation. However, this is not to be understood 
as limiting, and the described procedures can be applied to bidirectional tunnels as 
well. 

The method for setup of bi-directional MPLS tunnels provides means for both 
symmetric and asymmetric tunnels. Having a voice service or video conferencing, a 
symmetric bi-directional tunnel can be preferable. In contrary, when the bi-directional 
tunnel is used to support video streaming, an asymmetric tunnel, where the 
bandwidth for the upstream path is lower than in the downstream path, can optimally 
fit to the traffic requirements. The method according to the invention does not impact 
the procedures for set up symmetric/asymmetric tunnels. 

The MPLS architecture does not assume a single label distribution protocol, and 
thus, in the control plane different signalling protocols like Label Distribution Protocol 
(LDP) and Resource Resen/ation Protocol (RSVP) can be used. Initially, RSVP was 
designed to fulfil the Integrated Services (IntServ) concept for implementing QoS in 
standard IP-based networks. Employing extensions in RSVP with several additional 
objects allow to use RSVP as a signalling protocol for providing TE in MPLS. The 
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extended RSVP is known as RSVP-TE and it is described in detail in D. Awduche, L. 
Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, "RSVP-TE: Extensions to RSVP for 
LSP Tunnels", RFC 3209, December 2001. In particular, the extended RSVP 
protocol supports the instantiation of explicitly routed LSPs, with or without resource 
reservations. It also supports smooth rerouting of LSP tunnels, pre-emption, and loop 
detection. 

In the description of the present invention below, RSVP-TE is considered as an 
exemplary signalling protocol. However, it is understood that the invention can also 
be applied to other particular protocols providing data tunnels in a packet switched 
network. Two mechanisms are currently available in RSVP-TE, which allow to 
perform changes on existing LSP tunnels. These mechanisms are: 

- MPLS-based recovery, which assures the re-routing of a LSP when link or node 
failures occur. The framework for this mechanism is described in RFC 3469 and a 
proposed solution can be found in "Fast Reroute Extensions to RSVP-TE for LSP 
Tunnels", where two different techniques for local repair - one-to-one backup 
(creates detour LSPs at each potential point of local repair) and facility backup 
(creates a bypass tunnel to protect a potential failure point) are proposed. 

-LSP modification as proposed in RFC3209. 

Common to both mechanisms cited above is that the SESSION object in RSVP-TE's 
"Path" message (see RFC 3209) is kept the same, which means that the ingress and 
egress nodes of the LSP tunnel, as well as LSP ID are not changed. Thus, neither of 
the above mechanisms can be used for signalling in the present invention, since 
having a moving MH, the location of the egress LSR changes. 

Therefore a method is needed to provide mobility for a mobile host in a wireless 
network with multi-protocol label switching deployed in the core network, ensuring 
uninterrupted routing of packet data. 

In CA2292252 "SYSTEM AND METHOD FOR MOBILE SPECIFIC LABEL EDGE 
ROUTER OPERATION WITHIN A CORE AND EDGE NETWORK", a packet 
switched communications network utilizes a mobile specific label edge router (MLER) 
configured with mobility management functionality. The MLER supports the handing 
over of a call from a label switched path to a first MLER associated with a currently 
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serving radio base station to another label switched path for a second MLER 
associated with a target base station. In the disclosed method, paths are available 
between Label Edge Router (LER) and BS. At handover, the Label Edge Router 
changes the MPLS header of the data packets destined to the old base station with 
MPLS labels targeting the new base station. CA2292252 proposes a segmentation of 
the LSP within the MPLS domain, where an intermediate LER changes the packet's 
header. This requires extended functionality of the intermediate LER. Therefore a 
simplified method is needed with minimum additional requirements to intermediate 
nodes of the core network. 

WO0045560A2 "PUBLIC MOBILE DATA COMMUNICATIONS NETWORK' is an 
example of a public mobile access network using a home/foreign agent model where 
the home and foreign agents transfer data packets over the public mobile access 
network via a data tunnel. The Mobile IP packets are carried using MPLS LSPs. The 
home agent is located at a point of presence near to Internet backbone and each 
base station has implemented foreign agent functionality. A data tunnel is established 
between the home agent and one of the foreign agents. WO0045560A2 assumes 
Mobile IP that runs over MPLS LSP. This requires extended functionality from the 
mobile host. Therefore a method is needed which relieves the mobile host largely 
from mobility management tasks. 

In the method disclosed in WO2003030467A2 "MPLS DATA TRANSMISSION IN 
PACKET-ORIENTED MOBILE RADIO NETWORKS", a unique MPLS label is 
assigned to each terminal. This MPLS label allows unambiguous addressing of the 
data packets to the terminal. The routers tunnel the information packets, using either 
the MPLS or another tunnelling protocol. This provides a method for the end terminal 
to notify a MPLS router about its unique MPLS label. Then the MPLS router tunnels 
the data packets to the end terminal using label stacking. WO2003030467A2 
assumes that each terminal has a unique MPLS label allowing the tunnelling from 
ingress point to the mobile host. This requires an adaptation of the signalling in the 
radio access network. Therefore there is a need for a method which does not include 
the mobile host in the MPLS functionality. 

The introduction of MPLS in mobile networks incorporates the advantages of packet- 
switched network with possibility to provide QoS (especially relevant for real-time 
services) and TE. Since the MH roams between BSs (and consequently between 
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ARs), the egress LSR terminating the MPLS tunnel may change during handover. In 
such a scenario an appropriate method to provide mobility to the MH is needed. 
Currently known schemes for employing mobility in MPLS are based on Mobile IP 
and require that the MH accepts a new IP address when it registers at the new AR. 

jhepe is a need for an improved and simplified method to provide mobility for a 
mobile host in a wireless network, in particular in the case when the egress node is 
changed during a handover. 
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SUMMARY OF THE INVENTION 

Hence, it is an object of this invention to provide mobility in an improved and 
simplified way to a mobile host in a wireless network with multi-protocol label 
switching deployed in the core network. It is another object of the invention to provide 
a possibility to maintain a defined quality of service of the packet switched connection 
while the mobile host is moving in the service area of the wireless network. 

This object is achieved with the method and system of the independent claims. 
Possible embodiments of the invention are specified in the dependent claims. 

In one embodiment of the present invention a method is provided comprising the 
steps of (a) setting up a first multi-protocol label switching tunnel from an ingress 
node to a first egress node serving a first radio access network domain and, if the 
mobile host moves from a service area of the first radio access network domain to a 
service area of a second radio access network domain, (b) setting up a second multi- 
protocol label switching tunnel from the ingress node to a second egress node 
serving the second radio access network domain, the mobile host having an IP 
address in step (b) identical with an IP address assigned to the mobile host in step 
(a). 

The method of setting up a new tunnel to the second (new) egress node instead of 
re-routing the existing tunnel provides the advantage of compatibility with existing 
resource reservation protocols, as the tunnel end point address is a part of the tunnel 
identifier. The mobility handling is simplified because it can be managed in the 
ingress node without requiring additional functionality in intermediate nodes and the 
requirement on the functionality of the MH is reduced. 

In another embodiment the second MPLS tunnel may have a quality of service 
parameter equal to a quality of service parameter of the first MPLS tunnel. This 
ensures that the quality of service does not change when the MH moves inside the 
service area of the wireless network. 

In a further embodiment the difference between Identifiers of the first and second 
MPLS tunnels is only a tunnel end point address. This provides the advantage of 
simplified signalling and reduces traffic necessary for signalling in the core network. 



wo 2005/096556 PCT/EP2004/003421 

9 

In still a further embodiment the second MPLS tunnel is built up before the first MPLS 
tunnel is torn down. This embodiment provides the advantage of improved reliability 
avoiding the risk of loss of data packages. 

In still another embodiment, the setup of the second MPLS tunnel may be initiated 
from the first egress node. 

This embodiment provides the advantage of simplified signalling, as the first (old) 
egress node has all information necessary to request the setup of a new tunnel to the 
second (new) egress node. 

In still a further embodiment, the method may comprise the steps of (c) informing the 
first egress node about the handover; (d) sending, by the first egress node, (d1) an 
acknowledgement for attachment to the second egress node, and (d2) a message to 
the ingress node with information about the second egress node; (e) starting, by the 
ingress node, upon reception of the message specified in (d2), the setup of a second 
multi-protocol label switching tunnel to the second egress node; (f) completing, by the 
second egress node, after receiving the acknowledgement as specified in (d1) and 
signalling from the ingress node concerning the setup of the second multi-protocol 
label switching tunnel, handover procedures in the network; (g) switching, by the 
ingress node, traffic from the first to the second tunnel when a tunnel setup 
acknowledge is received; and (h) tearing down the first tunnel by the ingress node. 

This embodiment provides the advantage of quick and reliable signalling while 
requiring only one element in the protocol, which is not part of the current standard 
and has to be newly introduced. 

In still a further embodiment, step (c) comprises (c1) informing, by the mobile host, 
the second egress node about the IP address of the mobile host and an IP address 
of the first egress node; and (c2) requesting, by the second egress node, an 
authorization from the first egress node. 

In still another embodiment the message in step (d2) is a dedicated message in a 
resource reservation protocol. This embodiment provides the advantage of 
compatibility with existing protocols. 
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In still another embodiment the message in step (d2) contains a dedicated object in a 
resource reservation protocol. This embodiment provides the advantage of 
compatibility with existing protocols while at the same time minimising signalling 
traffic, as identical elements common to both tunnels are not repeated in step (d2). 

In still a further embodiment the first egress node is informed in step (c) about the 
handover and about an identifier of the second egress node by the mobile host. This 
embodiment may work also in cases where there is no direct communication 
between first and second egress node possible over the core network, for example 
with loosely coupled radio access network domains. 

In still a further embodiment the ingress node checks in step (e) for other available 
tunnels to the mobile host via the first egress node and starts a set up of a tunnel to 
the second egress node for each such tunnel. This embodiment has the advantage 
of greatly reducing signalling between the first egress node and the ingress node, 
because the first egress node has to send the message in step (d2) only once for all 
existing tunnels to the same MH. 

In still a further embodiment the setup of the second multi-protocol label switching 
tunnel is initiated from the second egress node. 

In still another embodiment the method may comprise the steps of (i) informing, by 
the mobile host, the first egress node about an IP address of the second egress 
node; (k) sending context information from the first egress node to the second egress 
node; (I) sending a request from the second egress node to the ingress node to set 
up the second multi-protocol label switching tunnel; (m) starting, by the ingress node, 
upon reception of the request specified in (c), the setup of the second multi-protocol 
label switching tunnel to the second egress node; (n) completing, by the second 
egress node, after receiving signalling from the ingress node concerning the setup of 
the second multi-protocol label switching tunnel, handover procedures in the network; 
(o) switching, by the ingress node, traffic from the old tunnel to the second tunnel 
when a tunnel setup acknowledge is received; and (p) tearing down the old tunnel by 
the ingress node. 
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This embodiment provides the advantage of quick and reliable signalling while 
requiring only one element in the protocol, which is not part of the current standard 
and has to be newly introduced. 

In still a further embodiment, the request in step (I) may be a dedicated message in a 
resource reservation protocol. This embodiment provides the advantage of 
compatibility with existing protocols. 

In still a further embodiment, the request in step (I) may be a dedicated object in a 
resource reservation protocol. This embodiment provides the advantage of 
compatibility with existing protocols while at the same time minimising signalling 
traffic, as identical elements common to both tunnels are not repeated in step (I). 

In still another embodiment, the ingress node checks in step (m) for other available 
tunnels to the mobile host via the first egress node and starts a set up of a second 
tunnel for each such tunnel. This embodiment has the advantage of greatly reducing 
signalling between the first egress node and the ingress node, because the first 
egress node has to send the message in step (I) only once for all existing tunnels to 
the same MH. 

In still another embodiment, the wireless network is a cellular network. This 
embodiment provides the advantage of compatibility with existing cellular networks. 

In still another embodiment, the wireless network is a wireless local area network. 
This embodiment provides the advantage of compatibility with existing local area 
networks. 

In an embodiment, a telecommunication system comprises a multi-protocol label 
switching network with a plurality of label switching routers forming nodes of said 
network, one of said nodes being configured as ingress node to provide connection 
to an external packet switched network; a mobile host having an Internet protocol 
address and being configured to receive packet data; a plurality of radio access 
network domains, each of said radio access network domains being configured to 
provide wireless connection between one of said nodes and said mobile host, said 
network being configured to set up a first multi-protocol label switching tunnel from 
said ingress node to a first egress node connecting a first radio access network 
domain belonging to a first service area where said mobile host is located, and, if the 
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mobile host changes its location from said first service area of said first radio access 
network domain to a second service area of a second radio access network domain, 
to set up a second multi-protocol label switching tunnel from said ingress node to a 
second egress node connecting said second radio access network domain, wherein 
said mobile host does not change said Internet protocol address. 

A telecommunication system according to this embodiment provides the advantage 
that it can be obtained by upgrade of existing systems, due to the compatibility with 
existing resource reservation protocols. There is no requirement for additional 
functionality in intermediate nodes and the requirement on the functionality of the MH 
is reduced. 

In a further embodiment, an apparatus forming a first egress node of a multi-protocol 
label switching network being configured to receive packet data from an ingress node 
of said network through a mu I ti -protocol label switching tunnel and forward said 
packet data to a mobile host via a first radio access network domain, is further 
adapted to carry out the steps of sending, upon receiving information about a 
handover of said mobile host from said first radio access network domain to a second 
radio access network domain, an acknowledgement message to a second egress 
node connecting said second radio access network domain; and sending a message 
to said ingress node with information about said second egress node. 

An apparatus according to this embodiment can advantageouisly serve as egress 
node in a telecommunication system according to the preceding embodiment. 

In still another embodiment, an apparatus forming an ingress node from an external 
packet switched network to a multi-protocol label switching network, being configured 
to receive packet data from said external network and forward said packet data to a 
mobile host via a multi-protocol label switching tunnel, a first egress node of the 
multi-protocol label switching network, and a first radio access network domain, is 
further adapted to carry out the steps of starting, upon reception of a message from 
said first egress node with information about a second egress node connecting a 
second radio access network domain, into which the location of said mobile host is 
handed over, a setup of a second multi-protocol label switching tunnel to said second 
egress node; switching, upon reception of a tunnel setup acknowledge from said 
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second egress node, traffic from said first to said second tunnel; and tearing down 
said first tunnel. 

An apparatus according to this embodiment can advantageously serve as ingress 
node (gateway) in a telecommunication system according to another embodiment of 
this invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings are incorporated into and form a part of the 
specification for the purpose of explaining the principles of the invention. The 
drawings are not to be understood as limiting the invention to only the illustrated and 
described examples of how the invention can be made and used. Further features 
and advantages will become apparent from the following and more particular 
description of the invention, as illustrated in the accompanying drawings, wherein 

Figure 1 shows an exemplary architecture of a wireless network. 

Figure 2 illustrates a handover of a mobile host between two egress nodes of the 
core network. 

Figure 3 illustrates the protocol stacks in the entities shown in Figure 2. 

Figure 4 depicts the signalling flow between the entities involved in the handover 
procedure when the setup of the new MPLS tunnel is initiated from the first (old) 
egress node. 

Figure 5 shows an alternative to the signalling flow shown in Figure 4. 

Figure 6 shows thiB signalling flow between the entities involved in the handover 
procedure when the setup of the new MPLS tunnel is initiated by the second (new) 
egress node. 

Figure 7 illustrates a procedure for handling multiple tunnels to a mobile host 
Figure 8 shows the format of a MPLS tunnel identifier. 
Figure 9 shows the format of a SESSION^ATTRIBUTE object in RSVP-TE. 
Figure 10 shows the constitution of a PATH message in RSVP-TE. 
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Figure 1 1 shows a possibility for a new message in RSVP-TE requesting the setup of 
a new MPLS tunnel from the ingress node. 

Figure 12 shows a possibility for a new object in RSVP-TE requesting the setup of a 
new MPLS tunnel from the ingress node. 

DETAILED DESCRIPTION OF THE INVENTION 

The exemplary embodiments of the present invention will be described with 
reference to the figure drawings wherein like elements and structures are indicated 
by like reference numbers. 

Figure 1 gives ah example of a network structure 100 where TE MPLS is deployed in 
a wireless network consisting of core network 113 and radio access network (RAN). 
In the RAN several access technologies could be supported, e.g. wireless local area 
network (WLAN), 3rd Generation (3G) RAN and future 4th Generation (4G) RAN or 
cordless technologies like DECT. Each of the different radio access technologies is 
organized regionally in radio access domains managed by an access router (AR). 
The ARs are connected to the Core network 113 through a Core Edge Router (CER). 
3G and 4G access domains 104, 105 are connected to CER2 8. 

The MPLS tunnel 4 or 5 is set up between an ingress LSR 1 in the mobile network 
(e.g. Gateway, GW) and an egress LSR 2 or 3, e.g. NoA (AR or base station, BS). 
The packets destined to a MH 6 are encapsulated at the ingress LSR 1 (i.e. MPLS 
label is added to the IP header), transported over the previously set up MPLS tunnel 
4, de-capsulated at the egress LSR 2 and transported further according to the native 
IP address 7. The case is regarded where the GW 1 performs also the functionality of 
Foreign Agent (FA) as described in the MIP specification RFC 3344, and thus, it can 
assign a CoA address 7 to a foreign MH 6 which is then valid within the whole mobile 
network 100. The egress LSR 2 is implemented in the NoA, where the MH 6 needs to 
authenticate at handover. In the system architecture shown in figure 1 , the NoA is 
AR, but in other scenarios is can be a BS. The MH 6 does not support MPLS. 
Further, it can be seen from figure 1 that the MPLS tunnel is terminated at the AR, 
since the packet transport within the radio access domain 104 is assumed to be 
performed in Layer 2 and one radio access domain forms a kind of Local Area 
Network (LAN). However, it is possible that the MPLS tunnel is terminated at another 
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node, as for example BS, where the functionality according to the invention is 
implemented. 

The MH 6 is a mobile computing device like for example a notebook or 3G's User 
Equipment (UE) etc. The MH 6 is connected via wireless link with a BS 113, which 
terminates the wireless communication and assures wire line packet-switched 
oriented connection with further entities in the mobile network. The BS might be the 
last entity, which terminates the MPLS tunnel 4. 

When the MH 6 moves in the direction of arrow 115, such that it enters the service 
area of BS 114 and is about to leave the service are of BS 113, a handover is 
necessary, not only between BS 113 and BS 114, but also between the first RAN 
domain 104 and the second RAN domain 105. In order to be able to continuously 
deliver data packets to the MH 6, the network builds up a new LSP 5 to the second 
egress node 3. The MH's location database is not distributed in the network, but 
rather concentrated in the ingress LSR, where the database is created and 
maintained. Employing the database, the ingress LSR can map each incoming data 
packet to a MPLS tunnel based on the IP address. Thus it is not necessary to change 
the IP address of the MH as long as the MH is roaming within the same wireless 
network. 

Referring now to figure 2, a detail of the wireless network 100 is shown. First, the 
mobile host 6 has a wireless connection to the old egress LSR 2, which receives data 
packets from the gateway or ingress LSR 1 over a first tunnel or LSP 4. In the 
example of figure 2, the LSP passes one intermediate LSR 8, which may be the core 
edge router. In another example, LSP 4 might pass a plurality of such intermediate 
LSRs. After a handover, the MH 6 has a wireless connection to the new egress LSR 
3. A new LSP 5 is built up from ingress LSR 1 to the new egress LSR 2 and the data 
traffic is switched from LSP 4 to LSP 5. After that, the old LSP 4 may be torn down. 

Figure 3 illustrated the protocol stack in the data plane of a MPLS network. 301 is the 
protocol stack of the gateway 1 , 302 belongs to the intermediate LSR 8, 303 to the 
respective egress LSR 2 or 3, and 304 to the mobile host 6. Every pair of 
neighbouring nodes in the network maintains a bidirectional data connection 305, 
306 in the MPLS protocol plane. The MPLS tunnel 307 is a virtual point-to-point 
connection from ingress node 1 to egress node 2 or 3. It is implemented by sending 
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encapsulated data packets hop-wise over the MPLS data connections 305 and 306. 
The egress node 2 or 3 forwards the received data packets to the MH 6, for example 
through a connection 308 in layer 2 of the radio access network protocol. 

Figure 4 shows an illustrative example of a method to set up a new MPLS tunnel 
from the ingress node to a new egress node to which the mobile host is handed over, 
initiated by the old egress node where the mobile host has been attached so far. The 
embodiment described In Figure 4 exhibits the advantage that the old egress node 
has exact knowledge of the (1) MH's authorization and connection session 
parameter, (2) MPLS tunnel's ingress node, (3) tunnel traffic parameters and (4) the 
IP address of the new egress node. A detailed description of the steps for setting up 
the new MPLS tunnel are described as follows: 

When the MH detects in step 401 a new NoA (will be the new egress LSR), the MH 
requires In step 402 authentication and informs it about its own IP address and the IP 
address of the current (old) NoA (old egress LSR). 

The new egress LSR does not know, if the MH is authorized for using the network 
resources, and therefore, it requests in step 403 an authorization from the old egress 
LSR, which still serves the MH. Extensible Authentication Protocol (EAP) represents 
one possibility how the communication can proceed between MH and new egress 
LSR, as well as between new egress LSR and old egress LSR. 

When receiving a request from the new egress LSR, the old egress LSR checks in 
step 404 its database. If the MH is currently served (i.e. also authorized and active 
tunnels are established from the Gateway) by the old egress LSR, the LSR initiates 
two activities to enable the handover: (i) it sends an acknowledgement for attachment 
405 to the new egress LSR and (ii) it sends a message 406 to the ingress LSR with 
an update of the new egress LSR. The latter message includes e.g. the IP addresses 
of the new egress LSR and of the MH. The ingress LSR needs the information about 
the concerned MH because it should update its database, where the incoming IP 
packets are classified to the MPLS tunnels according the MH's IP address. 

At receiving the update message from the egress LSR, the ingress LSR starts in step 
407 the setup of a new TE tunnel to the new egress LSR with the same parameter as 
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the old tunnel. During the setup procedure, the ingress LSR still sends the MH's 
traffic on the old tunnel. 

After receiving the acknowledgement for attachment and the tunnel setup signalling, 
the new egress LSR completes the handover procedures in the RAN in order to 
accomplish the whole handover of the MH. 

Finally, when the tunnel setup acknowledgement 408 is received by the ingress LSR, 
it switches in step 409 the traffic from the old to the new tunnel and tears down the 
old tunnel in step 410. 

Referring now to figure 5, alternatively to the signalling flow shown in 403 of figure 4, 
the old egress LSR can obtain the new egress LSR's identifier (e.g. IP address) by 
the MH as shown in step 501 . This would be feasible in the case where the network 
configuration does not allow a direct communication between new and old egress 
LSRs (e.g. with loose coupling between RAN domains). In this scenario, the MH can 
inform the old egress LSR about the new NoA (new egress LSR) and consequently 
the old egress LSR initiates the signalling to the ingress LSR. 

An advantage of the methods described in figures 4 and 5 is that the old egress LSR 
can directly signal the identifier (e.g. IP address) of the new egress LSR's to the 
ingress LSR, which speeds up the procedure by saving the delay of additional 
signalling, which would otherwise be necessary. 

Figure 6 illustrates another embodiment of the invention, where the signalling 
initiated by the new egress LSR. This option is feasible in the case, where the new 
and old egress LSRs communicate with each other in order to exchange traffic 
context parameters, like for example the existing tunnel traffic parameters. In the 3rd 
Generation Partnership Project the traffic context parameters are called PDP context. 
In step 601 , the new egress LSR sends periodically a broadcast message. In case of 
version 6 of the Internet protocol, for example, a router advertisement message is 
sent every 3 seconds. Upon receiving it, the MH informs in step 602 the old egress 
node about the IP address of the new egress node. Subsequently, the old egress 
LSR communicates the traffic context in step 603 to the new egress LSR. In this way 
the new egress LSR is informed about the identifier (IP address) of the ingress LSR, 
which is a part of the MPLS tunnel parameter contained in the context. Now, the new 
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egress LSR can contact the ingress LSR in step 604 and require the setup of a new 
MPLS tunnel to the new egress LSR. The signalling is completed by steps 605 to 608 
in the same way as described before in connection with figure 4. 

In the procedures described above, a setup of one MPLS tunnel per user is 
regarded. However, the method can also be applied in cases, in which one user is 
connected via multiple tunnels to the gateway. This is the case when the tunnels are 
set up per application because different applicatidns may have different QoS 
requirements. When a user of a MH connected to the gateway via multiple tunnels 
moves to new NoA, then one of the methods described above can be applied for 
each of the tunnels separately. However, this process can be optimised in another 
embodiment with the exemplary procedure shown in figure 7. When the ingress LSR 
receives a notification message from the old egress LSR to establish one new tunnel 
to the new egress LSR, the ingress LSR starts procedure 700. First, in step 701 , a 
new list is created having the existing MPLS tunnel specified in the request message 
as first entry. Then the Ingress LSR checks its database in step 702 for other 
available tunnels to the same user. Other tunnels found as a result of this search are 
added to the list. In step 703, the ingress node sets up a new MPLS tunnel to the 
new egress LSR for the first entry in the list, which is deleted in step 704. In step 705, 
it is checked whether the list is empty. If this is the case, the procedure is tenninated 
in step 706. Otherwise it jumps back to step 703 to treat the next entry in the list. 

The methods proposed so far can be applied for both uni-directional and bi- 
directional MPLS tunnels. The procedures described above will be the same in both 
cases, since the setup of bi-directional tunnels is initiated as usual by the ingress 
LSR (initiator) and the only difference to uni-directional tunnels are the RSVP-TE 
message formats. 

Referring now to figure 8, an exemplary data structure 800 is shown, which 
unambiguously identifies an MPLS tunnel. It comprises two objects from the RSVP- 
TE protocol, namely a SESSION object 801 and a SENDER_TEMPLATE or 
FILTER_SPEC object 802. The SESSION object 801 contains the IP address 803 of 
the tunnel end point, i.e. the egress node of the network, a tunnel identifier 805 and 
an extended tunnel identifier 806. Field 804 has no meaning in the context of the 
present invention and may be filled with zeroes. The SENDER_TEMPLATE or 
FILTER_SPEC object contains the IP address of the tunnel sender, i.e. the ingress 
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node of the network, and the tunnel identifier 809. Field 808, again, is filled with 
zeroes. The structure in figure 8 is only an example of a data structure Identifying a 
tunnel. Other structures could be thought of serving the same purpose. 

Figure 9 shows the data structure of a SESSION_ATTRIBUTE object 900 in RSVP- 
TE as an example of a data structure conveying QoS information. Fields 901 to 903 
are optional and not explained in further detail. Field 904 specifies the priority of the 
tunnel in comparison to other traffic with respect to taking resources and can assume 
a value between 0 and 7. Field 905 specifies the priority of the tunnel for holding 
resources. The flags 906 are control switches concerning the routing of the tunnel 
and are not regarded in detail in this context. Field 908 contains a null padded 
session name and field 907 the length of this name. In other protocols other 
structures than that shown In figure 9 could serve the same purpose of specifying the 
quality of service of the tunnel. 

Figure 10 illustrates the structure of a RSVP-TE PATH message 1000, which is sent 
by the ingress node in order to built up a new tunnel, like for example in steps 407 
and 605 of figure 4 and 6, respectively. It contains the SESSION object 801 
explained in conjunction with figure 8, the SESSION_ATTRIBUTE object 900 from 
figure 9 and the SENDER_TEMPLATE object from figure 8. The EXPLIClT_ROUTE 
object contains subobjects defining network nodes which should or must be passed 
by the route of the tunnel. Other fields of the PATH message 1000 are not explained 
in more detail. 

According to one embodiment of the present invention, the difference of the identifier 
between the old and new tunnel is only the tunnel end point address 803. This 
means that the same SENDER_TEMPLATE and FILTER_SPEC objects 802 
together with the modified SESSION 801 and EXPLICIT_ROUTE 1005 objects are 
sent with the Path message 1000 along the path of the new MPLS tunnel. Since the 
mobile operator has a perfect knowledge of the network's topology, the route for the 
new tunnel can advantageously be determined fast. 

For the implementation of the proposed method a new object or message is 
necessary in the protocol for the request to set up a new MPLS tunnel for an existing 
one, used for example in step 406 or 604. 
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Figure 11 illustrates an exemplary proposal for a possible structure of such a 
message 1 1 00. As the identifier of the new requested tunnel differs from the identifier 
of the old existing tunnel only by the end point address, message 1100 may contain 
besides a header 1101 only the old SESSION object with the IP address of the old 
egress node and the new SESSION object with the IP address of the new egress 
node. Thus, message 1 100 can be kept advantageously short. 

The case where a new object 1200 (normally included in the Path message) in the 
protocol is used for the request of the setup of a new tunnel, is illustrated in an 
example in figure 12. In this proposal, object 1200 is obtained by an extension of 
SESSION object 801, to which the IP address 1201 of the new egress node is 
appended. 

As a possible advantage, the procedures described in figures 4 to 6 allow seamless 
mobility for the MH, because the connection with the correspondent counterpart is 
kept alive during handovers. These handovers can be between base stations within 
both the same or different access technologies. The described handover procedures 
in the core network assure the mobility of the tunnels, and may fulfil this mobility in a 
fast manner without packet losses. This is achieved by the principle of "make-before- 
brake", as the new MPLS tunnel is set up before the traffic is switched on the new 
tunnel, and last the old tunnel is torn down. 

To avoid the negotiation of the session QoS parameters between MH and networks 
managing entity about the traffic context, the proposed method uses the same tunnel 
parameter as in the old tunnel. Another benefit of the proposed method is that its 
deployment requires no changes in the implementation of the signalling protocols 
apart from ingress and egress LSR. That is, no changes in the intermediate LSRs are 
necessary. Further, the proposed method makes widely use of available RSVP-TE 
signalling and minimises necessary modifications. 

Another benefit of the methods described above is that there is no need to Implement 
the micro-mobility Mobile IP in the network entities except in the Gateway and the 
MH. Since most of the routers distributed on the market now are MPLS-capable, the 
embodiments presented above can be implemented with handover procedures only 
on the network side. Signalling and processing effort is reduced compared to micro- 
mobility MIP extensions. Further the MH is relieved from mobility management tasks. 
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which are taken over by the network equipment. This enables a reduction of 
processing power and consequently leads to lower power consumption, smaller 
batteries and smaller MH. 

While the invention has been described with respect to the embodiments constructed 
in accordance therewith, it will be apparent to those skilled in the art that various 
modifications, variations and improvements of the present invention may be made in 
the light of the above teachings and within the purview of the appended claims 
without departing from the spirit and intended scope of the invention. In addition, 
those areas in which it is believed that those of ordinary skill in the art are familiar, 
have not been described herein in order to not unnecessarily obscure the invention 
described herein. Accordingly, it is to be understood that the invention is not to be 
limited by the specific illustrative embodiments, but only by the scope of the 
appended claims. 



